-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Avoid throwing errors for shared input/output IDs #4101
base: main
Are you sure you want to change the base?
Conversation
Now that it's not an error, it's safe to report
It's otherwise hard to tell that the error is scrollable Plus the scrolling is over the whole message rather than the part that overflows
* Renamed `showMessageInClientConsole()` to `showShinyClientMessage()` to improve clarity * Added `status` argument to `showShinyClientMessage()` to allow for different message types
I've held off on merging this because doing so would introduce breaking changes for the case where 2+ inputs have the same ID. It would also go back to pre v1.8.0 behavior for duplicate output IDs. Here is a short summary of behavior:
As it stands in this PR, the biggest change would be that using I think it might be better to avoid errors now, investigate if we can surface these warnings server-side as well, and then state an intention to elevate the warnings to errors in a future version of Shiny. |
Fixes #4100
Description
This PR refactors the Shiny Client Error console to allow client error messages to be communicated via events in addition to errors.
The primary goal is to avoid throwing an error from the binding validity checks for shared input/output ID errors. In practice, there were two problems with the binding validity checks throwing errors:
There are many cases where an app with shared IDs may still work, but by throwing an error we guarantee that the app breaks. Because we throw the error from Shiny's initialization code, we absolutely guarantee the app will not work, even if in practice the ID collision would not have caused problems.
We were previously guarding some errors behind dev mode being enabled, meaning that turning on dev mode could break an app that otherwise works. IMHO, dev mode should add information by showing users additional context or inforamtion, but should not introduce large breaking changes into the app.
By allowing the client error console to receive messages via event, we can now have
bindAll()
report binding issues without throwing or breaking the app.This refactor also improves the code organization and opens us up to future improvements in a few ways:
ShinyClientMessage
in the future to add, for example, informational messages differentiated by atype
prop.shiny:client-message
event.Note that we do still throw an error when we detect more than one of the same input IDs or output IDs (i.e.
"debug"
is used for two+ inputs or is used for two+ outputs). In theory, these apps could still work but would be much harder to reason about. More importantly, by still throwing in these cases, this PR only changes behavior in the narrow case of the shared input/output ID.Example
The following app currently works as expected in "production" but breaks when devmode is enabled. With this PR, the app works in both modes and a message is shown either in the console or in the client error console when devmode is enabled.
The problem can be seen in this shinylive.io app (as of 2024-07-15).